![[Amazon FSx for NetApp ONTAP] ボリュームの空きがあるのにバックアップができない場合はSSDの空き容量を確認しよう](https://devio2023-media.developers.io/wp-content/uploads/2022/08/amazon-fsx-for-netapp-ontap.png)
[Amazon FSx for NetApp ONTAP] ボリュームの空きがあるのにバックアップができない場合はSSDの空き容量を確認しよう
ボリュームの空きはあるのにバックアップできないぞ
こんにちは、のんピ(@non____97)です。
皆さんはAmazon FSx for NetApp ONTAP(以降FSx for ONTAP)のボリュームの空きがあるのにバックアップができない事象に遭遇したことはありますか? 私はあります。
それはSSDの空き容量に対してボリュームサイズが大きすぎるからかもしれません。
どういうことなのか以降紹介します。
いきなりまとめ
1 - MIN(ボリュームの空き容量, SSDの空き容量) / ボリュームサイズ × (1 - Snapshot Reserve)がVolume Full Threshold Percentの値を上回っている場合は、ボリュームのバックアップを取得することはできない- デフォルトではSnapshot Reserveは0.05で、Volume Full Threshold Percentは98%
- ボリュームの空きがあるのにバックアップができない場合はSSDの空き容量を確認する
- 対処方法は以下の3パターン
- ボリュームサイズを減らす
- Volume Full Threshold Percentを100%にする
- SSDの空き容量を増やす
- Logical Space Reportingを有効化してもバックアップはできない
- プロビジョニングするSSDのサイズを増やす場合は、SSDの空き容量が
ボリュームサイズ × (1 - Snapshot Reserve) × (1 - Volume Full Threshold Percent)以上になるようにサイジングする
事象の確認
まず、事象の確認をします。
サイズが100TBのボリュームを作成します。
ONTAP CLIで確認すると以下のようになります。
::> volume show -volume vol_100TB -fields size, available, used, percent-used vserver volume size available used percent-used ------- --------- ----- --------- ----- ------------ SVM vol_100TB 100TB 859.0GB 308KB 0%
ボリュームの空き容量(available)は859.9GBとなっていますね。これは以下記事で紹介している通り、ボリュームの空き容量がSSD(プライマリストレージ)の空き容量以上である場合に発生する事象です。
SSDの空き容量を確認すると、確かに859.0GBであることが分かります。
::> vserver show-aggregates
Available
Vserver Aggregate State Size Type SnapLock Type
-------------- -------------- ------- ---------- ------- --------------
SVM aggr1 online 859.0GB ssd non-snaplock
それでは、この状態でバックアップを取得してみます。
すると、Amazon FSx could not create a backup of your volume because the volume is full. Please try again after increasing the size of the volume or freeing up space. For more information, please see the Amazon FSx user guide: https[:]//docs.aws.amazon.com/fsx/latest/ONTAPGuide/troubleshooting.htmlと怒られてしまいました。
原因と対処方法
バックアップが失敗した原因を考えます。
FSx for ONTAPのバックアップはボリュームの使用率が98%を超えている場合は失敗します。
ボリュームスナップショットのために追加で消費される容量によってボリュームの使用率が 98% を超える場合は、バックアップスナップショットを作成することはできません。
しかし、ボリュームの使用率(percent-used)を確認すると0%でした。
これはボリュームのpercent-usedの値を使用していないためです。
AWSのFAQに以下のような紹介がされていました。
通常、ファイルシステムに十分な空き容量がないと、バックアップは失敗します。ボリュームに空き容量があっても、ボリュームはシンプロビジョニングされます。つまり、ファイルシステムのストレージ容量で消費されるのは、ボリュームに格納されているデータ分のみです。そのため、ボリュームに空き容量があっても、ファイルシステムの SSD (アグリゲート : aggr1) に空き容量がない場合があります。
FSx for ONTAP ボリュームのバックアップを作成する前に、Amazon FSx はまずボリュームがいっぱいでないことを確認します。FSx for ONTAP ではスナップショットを作成するために少量の空き容量が必要なため、ボリューム全体をバックアップすることはできません。FSx for ONTAP は、その使用率がボリュームの最大しきい値を超えている場合、ボリュームがいっぱいであると見なします。デフォルトの最大しきい値は 98% です。
さらに、FSx for ONTAP では、ボリュームの空き容量の報告時に、以下のうち小さい方が考慮されます。
- ボリュームの使用可能な容量。
- ファイルシステムの SSD 階層で使用可能な容量。
例えば、100 TB の SSD ファイルシステムを作成した場合、FSx for ONTAP はそのボリュームの空き容量が 1 TB であると報告します。つまり、FSx for ONTAP はボリュームが 99% フルと報告します。99% は、ボリュームのデフォルトの最大しきい値である 98% を超えています。ボリュームの 98% 以上がいっぱいになっていると報告されているため、ボリュームのバックアップが失敗する可能性があります。
肝心の「例えば〜」以降のSSDとボリュームのサイズは逆だと思いますが、ボリュームサイズが100TBで、SSDのサイズが1TBの場合、使用率は99%とレポートされるようです。
実際にNFSクライアントから確認すると、100%と見えていますね。
$ df -hT -t nfs4 Filesystem Type Size Used Avail Use% Mounted on svm-0404cd705c847e961.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/ nfs4 973M 1.7M 972M 1% /mnt/fsxn svm-0404cd705c847e961.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol_100TB nfs4 95T 95T 859G 100% /mnt/fsxn/vol_100TB
原因が分かったところで対応を考えます。
考えられる対応は以下があると思います。
- ボリュームサイズを減らす
- Volume Full Threshold Percentを100%にする
- Logical Space Reportingを有効化する
- SSDの空き容量を増やす
ボリュームのサイズを減らす
まず、ボリュームが過剰サイジングされていないか確認します。
過剰なサイジングがされている場合は、ボリュームのサイズを小さくします。
具体的にはSSDの空き容量が98%に収まるようにします。
今回はSSDの空き容量が859GBなので、ボリュームサイズは859 GB / (1 - 0.98) × 1024 = 43,980,800 MiB以下である必要があると考えます。
マネジメントコンソールからボリュームサイズを43,980,800 MiBに変更します。
変更後、ONTAP CLIからボリュームサイズが変更されたことを確認します。
::> volume show -volume vol_100TB -fields size, available, used, percent-used vserver volume size available used percent-used ------- --------- ------- --------- ----- ------------ SVM vol_100TB 41.94TB 859.0GB 368KB 0%
43,980,800 MiB / 1024 / 1024 = 41.943359375 TiBなので指定したサイズになっていますね。
NFSクライアントからも確認します。
$ df -hT -t nfs4 Filesystem Type Size Used Avail Use% Mounted on svm-0404cd705c847e961.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/ nfs4 973M 1.9M 971M 1% /mnt/fsxn svm-0404cd705c847e961.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol_100TB nfs4 40T 40T 859G 98% /mnt/fsxn/vol_100TB
ボリューム使用率が98%になりました。サイズが41.94TBではなく、40TとなっているのはSnapshot Reserveの5%分が加味されているためです。Snapshot Reserveが与える影響は後で検証します。
この状態でボリュームのバックアップを行います。すると、バックアップは正常に行え、ライフサイクルの状態も利用可能となりました。
ボリュームで過剰なサイジングをしてはいけない理由が増えましたね。
Volume Full Threshold Percent を 100% に変更する
次にVolume Full Threshold Percentを100%にします。こちらは先ほどのAWSのFAQに紹介されていました。
space-full-threshold-percent を 100% に上げる
FSx for ONTAP ボリュームはシンプロビジョニングされます。そのため、ファイルシステムよりも大きいサイズのボリュームをプロビジョニングすることができます。これにより、スナップショットの作成時に容量の問題が発生する場合があります。例えば、1 TB のファイルシステムに 100 TB のボリュームを作成する場合、NetApp ONTAP CLI を使用してスナップショットを作成できます。しかし、AWS Backup ではスナップショットを作成できません。1 TB のファイルシステムの場合、約 42 TB のボリュームのバックアップを作成することができます。ボリュームサイズ (TB) が増えると、AWS Backup はバックアップの作成に失敗します。
Volume Full Threshold Percentはボリュームがフルであると判断される閾値のことです。この閾値を超過するとEMSのエラーが発行されるようです。
- 「ボリュームがフル」しきい値は、ボリュームがフルであると判断される割合を示し、それを超えるとクリティカルな EMS エラーが生成される割合を示します。
- デフォルト値は98%です。
- このオプションの最大値は100%です。
- このしきい値を0に設定すると、ボリュームのスペースがフルであることを示すアラートが無効になります。
Volume Full Threshold Percentを100%にすることで、ボリュームがフルになったことをEMSで検知できなくなると予想します。ただし、2023/2/8時点ではFSx for ONTAPのEMSイベントを検知することができないの かつ イベントステータスを確認することはできません。そのため、こちらの案を紹介しているかもしれません。
実際にVolume Full Threshold Percentを100%に変更して、バックアップが取得できることを確認します。
# ボリュームサイズを100TBに戻しておく ::> volume show -volume vol_100TB -fields size, available, used, percent-used vserver volume size available used percent-used ------- --------- ----- --------- ----- ------------ SVM vol_100TB 100TB 859.0GB 400KB 0% # Volume Full Threshold Percentを確認 ::> volume show -volume vol_100TB -fields space-full-threshold-percent vserver volume space-full-threshold-percent ------- --------- ---------------------------- SVM vol_100TB 98% # Volume Full Threshold Percentを100%に変更 ::> volume modify -volume vol_100TB -space-full-threshold-percent 100% Volume modify successful on volume vol_100TB of Vserver SVM. # Volume Full Threshold Percentが100%に変更されたことを確認 ::> volume show -volume vol_100TB -fields space-full-threshold-percent vserver volume space-full-threshold-percent ------- --------- ---------------------------- SVM vol_100TB 100%
Volume Full Threshold Percentが100%に変更されたことを確認しました。この状態でバックアップを取得します。すると、バックアップは正常に行え、ステータスも利用可能となっています。
Volume Full Threshold Percentを変更することでバックアップができるということから、ボリュームの物理的な使用量 / ボリュームサイズが98%を超過しているかをAWS側で判断しているのではなく、Volume Full Threshold Percentの閾値をチェックしているかもしれません。
Logical Space Reporting を有効化する
先ほどの検証でボリュームの物理的な使用量 / ボリュームサイズが98%を超過しているかをAWS側で判断していそうではないということが分かりました。
ということで、次はLogical Space Reporting を有効化してみます。
Logical Space Reporting を有効化することで、クライアントから物理空き容量ではなく、論理空き容量を確認できるようになります。
早速試してみましょう。
# Volume Full Threshold Percentを98%に変更 FsxId05f72eb8f8d03c709::> volume modify -volume vol_100TB -space-full-threshold-percent 98% Volume modify successful on volume vol_100TB of Vserver SVM. # Volume Full Threshold Percentが98%に変更されたことを確認 FsxId05f72eb8f8d03c709::> volume show -volume vol_100TB -fields space-full-threshold-percent vserver volume space-full-threshold-percent ------- --------- ---------------------------- SVM vol_100TB 98% # Logical Space Reporting が有効化されているか確認 FsxId05f72eb8f8d03c709::> volume show -volume vol_100TB -fields is-space-reporting-logical vserver volume is-space-reporting-logical ------- --------- -------------------------- SVM vol_100TB false # Logical Space Reporting を有効化 FsxId05f72eb8f8d03c709::> volume modify -volume vol_100TB -is-space-reporting-logical true Volume modify successful on volume vol_100TB of Vserver SVM. # Logical Space Reporting が有効化されたことを確認 FsxId05f72eb8f8d03c709::> volume show -volume vol_100TB -fields is-space-reporting-logical vserver volume is-space-reporting-logical ------- --------- -------------------------- SVM vol_100TB true
Logical Space Reporting が有効化された状態でNFSクライアントからボリュームの空き容量を確認します。
$ df -hT -t nfs4 Filesystem Type Size Used Avail Use% Mounted on svm-0404cd705c847e961.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/ nfs4 973M 1.2M 972M 1% /mnt/fsxn svm-0404cd705c847e961.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol_100TB nfs4 95T 384K 95T 1% /mnt/fsxn/vol_100TB
空き容量は95Tで使用率は1%となっていますね。
この状態でバックアップを取得します。すると、バックアップは失敗してしまいました。
論理的な空き容量は見ていないようですね。シンプルにVolume Full Threshold Percentが閾値を超えているかで判断していそうです。
Snapshot Reserveが加味されるのか確認する
Volume Full Threshold Percentを100%にすることでバックアップを取得できるようになることは分かりましたが、ここで一つ疑問が湧いてきました。
それはVolume Full Threshold Percentの判定で使う値はSnapshot Reserve分を加味するのかです。
Snapshot Reserveはデフォルトで5%分割り当てられます。そのため、実際にユーザーが使える領域は残りの95%になります。例えば、ボリュームサイズが100TiBの場合は95TiBになります。
この時、Volume Full Threshold Percentの閾値に到達したかを計算する際に、ボリュームのサイズを使うのか、それともSnapshot Reserveが加味されたサイズを使うのが気になります。
100TBのボリュームのSnapshot Reserveを5%から90%に変更した時に、バックアップを取得できるか確認します。
# Logical Space Reporting を無効化 ::> volume modify -volume vol_100TB -is-space-reporting-logical false Volume modify successful on volume vol_100TB of Vserver SVM. # Logical Space Reporting が無効化されたことを確認 ::> volume show -volume vol_100TB -fields is-space-reporting-logical vserver volume is-space-reporting-logical ------- --------- -------------------------- SVM vol_100TB false # Snapshot Reserve を確認 ::> volume show -volume vol_100TB -fields percent-snapshot-space vserver volume percent-snapshot-space ------- --------- ---------------------- SVM vol_100TB 5% # Snapshot Reserve を90%に変更 ::> volume modify -volume vol_100TB -percent-snapshot-space 90 Volume modify successful on volume vol_100TB of Vserver SVM. # Snapshot Reserve が90%に変更されたことを確認 ::> volume show -volume vol_100TB -fields percent-snapshot-space vserver volume percent-snapshot-space ------- --------- ---------------------- SVM vol_100TB 90%
Snapshot Reserveを90%に変更した後、NFSクライアントからボリュームサイズを確認すると、10Tとなっていました。使用率も92%になっていますね。
$ df -hT -t nfs4 Filesystem Type Size Used Avail Use% Mounted on svm-0404cd705c847e961.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/ nfs4 973M 1.2M 972M 1% /mnt/fsxn svm-0404cd705c847e961.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol_100TB nfs4 10T 9.2T 859G 92% /mnt/fsxn/vol_100TB
それでは、この状態でバックアップを取得します。すると、バックアップは正常に行え、ステータスも利用可能となっています。
Volume Full Threshold Percentの判定で使う値はSnapshot Reserve分を加味するようですね。
SSDの空き容量を増やす
ボリュームの空き容量がSSDの空き容量以上である場合に、この事象は発生するのでSSDの空き容量を増やすことでも対応できます。
最後にSSDの空き容量を増やすことでも対応できます。
「SSDの空き容量を増やす」と聞くと、プロビジョニングするSSDのサイズを増やすことをイメージすると思います。
それ以外にも、不要なファイルやSnapshotを削除するといったアプローチもあります。SSDは増やすことはできますが、後から減らすことはできないので慎重に行いましょう。
プロビジョニングするSSDのサイズを増やす場合は、SSDの空き容量がボリュームサイズ × (1 - Snapshot Reserve) × (1 - Volume Full Threshold Percent)以上になるようにサイジングしましょう。
例えばサイズが100TiBで、Snapshot Reserveが5%、Volume Full Threshold Percentが98%のボリュームのバックアップを作成する場合は、SSDの空き容量が100TiB × (1 - 0.95) × (1 - 0.02) = 1.9TiBはあるようにサイジングを行います。
ボリュームの空きがあるのにバックアップができない場合はSSDの空き容量を確認
Amazon FSx for NetApp ONTAPのボリュームの空きがあるのにバックアップができない場合の原因と対処方法について紹介しました。
まずはSSDの空き容量を確認しましょう。その後は状況に応じてボリュームのサイズを減らしたり、SSDのサイズを増やすことになると思います。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
![[アップデート] Amazon Bedrock Agents のメモリ保持期間が最大 30 日から 365 日に変更されました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-e3065182082062711612153bbdcf1d96/c04359de689df2f56eb066576ab63fb5/amazon-bedrock)
![[アップデート]Amazon Connect のキューとルーティングプロファイルを管理コンソールから削除できるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-a14da8621c55bd17addadcead8e0e00f/c928a36480d9593938e8d8f65ba92537/amazon-connect)
